The invention relates to addressing a management object of a device in a device management system of the device.
The significance of device management is emphasized as the different data processing devices, such as mobile stations, become more complex. Various settings are required in the devices, such as settings associated with Internet access points, which are laborious and difficult to set manually by the user. Device management solutions have been developed for instance to solve this problem, by means of which for instance an administrator of a company's data system or a teleoperator is able to configure a device suitably. Usually device management refers to measures by which parties external to the device are able to change the configuration of the device, for instance change the settings or even some protocol used by the device. Not only setting associated with the device, but also user-specific data, such as user profiles, logos, ringing tunes and menus can be sent, allowing the user to modify the settings of the device into personal or the modification to take place automatically in association with device management.
One device management standard is SyncML device management (Synchronization Markup Language) based partly on the SyncML data synchronization standard enabling data synchronization. A synchronization server may serve as a device management server and a client device as the device management client. The client device acting as client from the point of view of device management sends information about itself (similarly to synchronization) to a management server performing device management in a session initiation message to the server, to which the management server responds by sending server management commands. The client device responds to these by status information, after which the server can end the session or send more server management commands. If the server sends more management commands, the client device should respond to these by status information. Having received status information, the server is always able to end the session or continue it by sending more device management commands. The device management protocol may also operate such that inquiries are first sent to the user about what he wants to update, and information about the user's selections is sent to the server. The server can then send the updates/operations requested by the user in the next packet.
In the client device, the matters to be managed are arranged as management objects. Management objects are entities in the client device and are manageable by the management server's management commands. The management object may be for instance an integer or a large entity, such as a background picture or a screensaver. In SyncML device management, the management objects are arranged in the form of a tree as a management tree, illustrated in FIG. 1. The management object may be a single parameter, a subtree or a data collection. For example, the management object ‘Vendor’ is a node, i.e. an interior object, since it has child objects ‘Screen Saver’ and ‘Ringing Tones’. The management object ‘Screen Saver’ is a leaf object, since it has no child objects. The management object ‘Ringing Tones’ is also a node or an interior node, since it has child objects. The content of the management object may also be a link addressing another management object. Each object can be addressed using a URI identifier (Uniform Resource Identifier). The URI of a management object is created by starting at the root ‘/’ and, traversing down the tree, each management object has a name, which is appended to the previous ones using ‘/’ as the delimiting character. For example, the management object ‘Ringing Tones’ can be addressed using the URI identifier ‘/Vendor/Ringing Tones/’. At least some management objects are preferably standardized (the SyncML device management standards presently include three standardized management objects). The management objects may be permanent or dynamic. Dynamic management objects can be added to the management tree from the client device or the management server.
New dynamic management objects have to be assigned a name in the management tree (the name acting as the address) such that the management tree is the same both in the management server and in the client device. If the client device is allowed to freely decide the name to be added to the management tree, the management server does not have the same tree, and the management commands given by the management server cannot be implemented. When a unidirectional message (unacknowledged) is used, the name could in no way be updated in the server. An example of a new management node is a document including WAP provisioning settings. A new management object (having different settings as child objects) can be created from the document and the settings comprised by it. A WAP provisioning document may include parameters that appear several times (e.g. several alternative proxy servers), and these parameters cannot be arranged in a management tree. A solution has been suggested for selecting the name, wherein a new identifier field for distinguishing the different properties from each other in the management tree is added to the management information, e.g. the WAP provisioning document. In this case, the address of the management object would have at least one more identifier, which would make the address still longer. For instance, in the case of the WAP protocol, changes would also have to be made to the WAP standard.